When using DataPower Probe sometimes a context is displayed as empty. although you know it is not.

Reason is that in DataPower Probe


Today I want to show you how you can get an idea on what the content of a context is, even when it is not displayed.

All screenshots below are done for Firefox web broser, with Chrome browser it is similar.

OK, so lets take this very simple Transform stylesheet value.xsl:

<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>
  <xsl:output omit-xml-declaration="yes" />
    
  <xsl:template match="/">
    <xsl:value-of select="."/>
  </xsl:template>
 
</xsl:stylesheet>


It just takes the XML input and outputs the string value of the Root Node which is
"... the concatenation of the string-values of all text node descendants of the root node in document order. ..."

So for input document "<a>1<b>2</b>3</a>" it returns just "123", see sample "curl" request and response returned:

$ echo "<a>1<b>2</b>3</a>" | curl --data-binary @- http://firestar:2050 ; echo
123
$

With Probe enabled for the service we get this INPUT context ...

image


... and this (empty displayed) OUTPUT context -- but we know that "123" is there ...
image


So how can we "see" what is in OUTPUT context?
The trick is to do a Probe "Export Capture":
image


It does not have to be stored, instead can be opened directly in your System's Archive Manager:
image


This is the content of the exported .zip file, we are interested in "xmlfirewall@value.zip":
image


Opening the .zip shows this -- only one folder with name being the transaction ID, there will be many normally:
image


Following the transaction ID we are interested in we select "0" for "request rule"
("1" is response rule, not present in loopback XML FW, there may be others for "called" rules).

And the context information now is available in 0.xml.gz, 1.xml.gz, (2.xml.gz, ... if there are more contexts):

image


Opening "1.xml.gz" for the OUTPUT context, search for "transaction-input>".
This gives you the opening and closing tag around the context content.

For the sample we have this:

... <transaction-input>&lt;?xml version="1.0" encoding="UTF-8"?>
&lt;wrap>123&lt;/wrap></transaction-input> ...

As you can see the "real content" (123) is framed by serialized <wrap> element.


This is a another sample (from INPUT context) for a JSON request against a Non-XML service ( {"alice":{"$":"bob"}} ):

... <transaction-input>&lt;?xml version="1.0" encoding="UTF-8"?>
&lt;wrap>&lt;hexbin>7b22616c696365223a7b2224223a22626f62227d7d0a&lt;/hexbin>&lt;/wrap></transaction-input> ...


Besides just looking for <transaction-input>...</transaction-input> you might whant to explore other data
in N.xml.gz as well (context variables, headers, service variables, ...).

 

Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>